Design Comments:

A unique identifier for this particular event assigned by the system in which the event occurred.

UsageNotes:

Identifier needs to be persisted by receiving applications, except for queries (queries cannot be retracted or undone). The identifier must be unique and different from the event identifier that is present on the request - it must be generated by the responding application.

Rationale:

Allows the event to be referenced (for undos) and also indicates whether multiple interactions were caused by the same triggering event. Also used for audit purposes.

Design Comments:

Identifies the trigger event that occurred.

Rationale:

This is mandatory because it is essential to understanding the meaning of the event.

Design Comments:

Describes the status of the control act, which is always complete (it happened).

Rationale:

Required for completeness of specification.

Design Comments:

Indicates the time the event (e.g. query, change, activation) should begin and occasionally when it should end.

Rationale:

The time an event becomes effective may differ from the time the event is recorded (i.e. it may be in the future or the past). For events such as 'suspend', an intended end date may also be indicated.

Design Comments:

Identifies why this specific message interaction (e.g. query, activation request, modification request) occurred.

UsageNotes:

The domain associated with this attribute will vary for each interaction and will be noted as part of the interaction description.

Rationale:

Allows identifying a reason for a specific action, such as 'reason for hold' or 'reason for accessing information'.

Design Comments:

Indicates the item(s) being acted upon by this trigger event.

Will be mandatory in wrappers with payload messages, otherwise not present.

UsageNotes:

If there are multiple subject items, the changes to all of them must be either accepted or rejected as a single action. I.e. One trigger event = 1 unit of work.

Rationale:

Provides information about the thing being created, modified or removed.

Design Comments:

This is the list of clinical and business issues that have been detected and/or managed involving the current action.

Rationale:

Any trigger event can result in errors or may allow for errors to be overridden or managed.

Design Comments:

Indicates whether or not objects of the trigger event are to be cascaded to the payload.

If true, associations in the parent act are conducted across the ActRelationship to the message payload (act). Conduction for each association is specifically indicated by each associations' contextControlCode value.

In other words, if the "subject" act relationship has contextConductionInd=true; THEN the subjectOf association is carried (to the regsitrationEvent act) according to the subjectOf.contextControlCode (AP = propogate to the reg event and add to any subject(s) (issues) already present).

Rationale:

Cascading of trigger event objects allows different messages to employ consistent and common objects.

Attribute is mandatory to ensure that cascading will be specified one way or another.

Design Comments:

This class contains information relevant to the registration of the payload item(s) into the Master File or Registry. This message is a response to a request to register (therefore, the mood is an event).

Rationale:

The RegistrationProcess act is the focal act of the message and therefore is mandatory

Design Comments:

Commonly called the Payload stub. Any interaction that uses this ControlAct Wrapper will replace this class with a Role-based domain Message Type

Rationale:

Defines the content of the registration and is therefore mandatory.

Design Comments:

This indicates the EHR repository the record is stored in.

Rationale:

Different repositories may have different access rules governing access to data. Knowing the custodian of the data also helps to provide context. As a result, this association is mandatory.

Design Comments:

Identifies "duplicate" records of the registered item that have been superseded by this record.

Rationale:

Provides support for merges.

Design Comments:

Identifies "duplicate" records of the registered item that have been superseded by this record.

Rationale:

Provides support for merges.

Design Comments:

Identifies the query being acknowledged

Rationale:

Allows linking of a response back to the request that triggered it and is therefore mandatory. Particularly useful when responses are deferred or queued.

Design Comments:

Indicates whether the query was successful or not.

Rationale:

Used to control receiver logic and is therefore mandatory.

Design Comments:

Identifies the total number of rows identified that matched the query.

Rationale:

Indicates the overall size of the result-set and is therefore mandatory. Particularly useful when only part of the result set is actually returned.

Design Comments:

Identifies the number of rows returned as part of this particular query response.

Rationale:

Provides a quick overview of the results of the query and is therefore mandatory

Design Comments:

Indicates the number of rows that still exist after the last row returned in this response.

Rationale:

Identifies how much data remains to be queried and is therefore mandatory.

Design Comments:

Unique number for this particular query.

Rationale:

Needed to allow continuation of queries and linking of query requests and responses and therefore mandatory.

Design Comments:

This allows the sender to indicate to the receiver that this query should follow an expedited processing flow.

Rationale:

Intended to convey the 'packaging' of query results. This attribute does not affect which rows are selected by the query, just the manner in which they are returned. For example, a batch file containing responses, a response message containing multiple payloads, or a stream of response messages (notifications) each identifying itself as a response to a query request.

Design Comments:

The number of response item repetitions that should be included in the initial response.

Rationale:

There may be a very large number of matching rows. To manage communication bandwidth, a limited set may initially be returned with further data retrieved by using query continuations.

Design Comments:

Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application.

Rationale:

Needed to quantify the types of records requested to be returned in the query.

Design Comments:

When more than one sort control is specified, this is the order of this sort element amongst the others.

Rationale:

This number determines which sort element is using primarily, secondary, etc. and is therefore mandatory.

Design Comments:

Name of the element to sort.

Rationale:

The name of the element is mandatory.

Design Comments:

Sets the ascending or descending nature of the sort request.

Rationale:

This element is required.